Summary

Gas optimizations to the Pulse contract that keep the requests on-chain.

Rationale

The motivation behind this PR is to see how cheap we can get the basic request/fulfill flow while still keeping full request state on-chain. This will let us treat the contract as the source of truth for state, greatly simplifying keeper implementation. It also eliminates a class of errors related to tracking chain state, improving reliability.

This is an alternative design to the gas optimizations done in #2492 , which make the opposite tradeoff: move request state off-chain (specifically the priceIds array) to gain gas savings at the cost of keeper complexity.

Results:
https://docs.google.com/spreadsheets/d/1AYcmnwDQp2OA8n0xfoTf-GtThmhsX1ahxMQilIua4b0/edit?gid=0#gid=0

Optimizations made:

• Make the priceIds array dynamically sized rather than pre-allocated to size MAX_PRICE_IDS. This makes the gas price dynamic based on the request, but it will still be predictable. The assumption here is that most users will use much fewer than the maximum price IDs in a single request.
• Only store an 8-byte prefix of the price IDs in the request. This takes the array from bytes32[MAX_PRICE_IDS] to bytes8[]. There is very low chance of collision at 8 bytes, and even at 4 bytes, so we can go even lower here.
  • Assuming the hash function gives uniformly random output, the first 64 bits (8 bytes) gives 2^64 possible values. Using the birthday approximation P ~= (n(n-1))/(2 * 2^64) (where P is the chance of a collision for n entries) gives 2.7e-12, which is very unlikely.
• Reduce datatype sizes for uints to more reasonable sizes. This saves a few storage slots in the state structs. We could go even lower on some of these, but perhaps I'm missing some context on why we chose such high numbers here.
  • Changed callbackGasLimit from uint256 to uint32, since this number can't exceed the block gas limit anyway
  • Changed exclusivityPeriod from uint256 to uint32, since we only support requests 60s into the future, and 32 bytes still lets us represent ~49k days in seconds.
  • Changed pythFeeInWei, baseFeeInWei, feePerFeedInWei, feePerGasInWei from uint128 to uint96 since 96 bytes still gives us the ability to represent up to ~79,228,162,514 ETH in wei. We could go lower here.

Notes:

• We will need to keep a mapping of prefix -> price feed ID in the keeper, since we can't directly query Hermes with just a prefix. That means we'll need to keep the price feed ID set up to date somehow (on demand when querying for a price? on a timer?)
• We can also further optimize the firstUnfulfilledSeq feature, as called out in the code:

// TODO: I'm pretty sure this is going to use a lot of gas because it's doing a storage lookup for each sequence number.
// a better solution would be a doubly-linked list of active requests.

• Current tests cover my changes
• Added new tests
• Manually tested the code